【レポート】AWS Summit Tokyo 2017：Amazon Innovation Dive Deep Session 1 ~Amazon Dash/DRS~ #AWSSummit

2017年05月30日(火)〜2017年06月02日(金)の計4日間に渡り、グランドプリンスホテル新高輪 品川プリンスホテル アネックスタワーで行われている『AWS Summit Tokyo 2017』。

当エントリでは2017年05月31日に行われた『Amazon Innovation Dive Deep Session 1 ~Amazon Dash/DRS~』に関する内容をレポートしたいと思います。

• AWS Summit Tokyo 2017（2017年5月30日～6月2日）｜AWS

セッション概要

当セッションの登壇者及び概要は以下の通り。

セッションレポート

• 開発者に限定的なコードを使ってすべてのサービス、コーヒーサービス、プリンターであっても自動的に注文ができる仕組みを提供
• Internet useful things。IoTといかに協業できるのか。
• アメリアのテディベアにはWi-Fiが組み込まれている、等IoTの波はどんどん押し寄せている。
• すべてのデバイスにIoTが組み込まれる。CX（Customer Experience)が重要となる。
• クラウドを活用して分析を行う。適切なタイミングでAmazonを使ってオーダーしてもらう。

開発者はDRSをどう活用するのか？

• DRSは3つの重要な技術のコンポーネントからなっている
  • LWA(Login with Amazon): OAuth2を使っている。これをつかってログインしてもらう。FacebookやTwitterのアカウントも使える。
  • DRS Restful APIエンドポイント: 標準に基づいたAPIエンドポイント。5つHTTPのエンドポイントを用意している。
  • 非同期のSNS通知サービス: SQSをSNSに使う人もいる。技術的な判断なのでアーキベースで決める。お客様が皆さんに代わって何をしているかを開発者に通知する。キャンセル等お客様の判断を通知する。

LWA(Login with Amazon)

• 既存のAmazonアカウントの仕組みで、開発者が容易に使えるようにする。
• モバイルSDKやJava web SDKを使用してLWAを呼び出す
• Oauth2スタンダードベース
• 掃除機にタイマーをセットする。モバイルアプリがセットで用意されている。
• そのWebページにて製品を選択する
• Amazonアカウントでサインインし開発者用の申込みに同意すると認証後のフローをwebで提供する(Post Authorization Flow)
• すべてのフローが完了するとLWAはアクセスコードを返す => access_token/refresh_tokenとアクセスコードを交換する

Post Authorization Flow

• お客様がこのログインは何なのかわかるようにDeveloper conigurable in LWA consoleにサービス名を入れる
• 発注に関する情報をお客様と共有する
• どの商品の配送を望むのか、を事前定義をして選んでもらうことで、お客様が驚かないようにする。
• Slot: 掃除機の場合、エアフィルターも必要だとするとバキュームのslotとエアフィルターのSlotが２つ出て来る。異なった製品が注文できるようにする。
• 送付先、請求先を見る。complete setupをクリックするとaccess_token/refresh_tokenが皆さんに返ってくる
• なるべくお客様に摩擦が少ない形で、また何を買っているのかわかるように作っている

DRS API エンドポイント

• Replenish: お客様の商品を注文
• SlotStatus: 使用状況をAmazonに通知（「毎日」の設定が望ましい)
  • 掃除機であれば毎日何％使われた、という状況を通知する
• DeviceStatus: デバイスがオンラインであることをAmaozonに通知(「毎日の」)
  • IoTデバイスはWi-Fiの接続がうまくいかない等、オフラインになることも多い。このステータスを使ってAmazonがオンラインであることを把握する
• Deregistration: AmazonアカウントからDRSの登録を解除
  • お客様が認証後のフローを完了した時点でRegistrationされる。
  • そのデバイスを売った、壊れたというときはこれを使って解除する
• SubscriptionInfo: お客さまの登録状況と詳細を問い合わせ
  • 開発者にアクティブにサブスクリプション状況を開示することで、お客様の状況を開発者にも見せる

SNS通知

• Order Placed
  • 足りなくなったら開発者のプラットフォームからAmazonに注文が入る
  • Amazonはお客様に通知をする
  • 24h以内であればそのオーダーをキャンセルできる
• Order Cancelled
  • お客様がキャンセルしたときにAmazonから開発者に通知する
• Device Registered
  • お客様がComplete Setupボタンをクリックした時に通知する
• Device Deregistered
  • デバイスが登録解除された時に通知する
• Subscription Changed
  • お客様がDRSに何か変更をかけた時に通知する。Management Websiteというページからできる。
  • 小さなバッグを使っているが大きなものに変えたい、というような場合はManagement Websiteで出来る。
  • UnSubscribeというスイッチがある。
• Item Shipped Notification
  • ステータスが"Order Placed"から"Order Shipped"に移行すると通知する。出荷完了の通知と配達日の通知

Device/App CX ガイドライン

• developer.amazon.com/drsでセルフサービスの登録ができる。ガイドラインもそこにある。
• DRSを利用するための様々な重要な事項が含まれているリンクです。
• 最初のボトルで問題が起きました、というコールがある
• 例えば初期段階でどれくらいの洗剤があるのか、というのが把握できていない場合に起こる
• こういう場合は最初にいくら在庫があるのかお客様に聞く、という事が書いてある
• Amazon向けに定義をする必要がある。名前やモデル、スロットの数、商品などの情報をAmazonに送ることでAmazonが把握する

ティザーページの作り方

• デバイスのヒーローイメージ、再注文する製品の詳細をフォーラムに作成する
• Amazonはティザーページを作成し、コンポジットIDを開発者にメールする
• FormがあるのでそこにPostすると出来る

お客様はDRSをどう使うのか

• DRSが搭載されたデバイスを購入
• 説明書の小さな紙を見ながらデバイスのネットワーク設定をする
• 3Pアプリを利用して製品洗濯のためLWAフローをたどる
• アプリ内で設定を完了
• デバイスの使用
• 消費を確認し、3Pサービスがその状態を利用する
• デバイスや3Pサービスが閾値に達した事を検知し、Amazonへ注文する

最後に

• https://www.hackster.io/contests/DRSでコンテストをやっている

まとめ

ユーザが注文しなくても商品の使用状況をチェックして自動的に注文をかけてくれる、というAmazon DRS(Dash Replenishment Service)。勝手に注文する、ということで便利な半面怖いイメージもあったのですが、何か合った時のキャンセルやデバイス自体の登録解除、使用状況のトレース方法など、アーキテクトとしてとても興味を惹かれる内容でした。